持久層是指那些可以把在系統間傳遞的資料暫時保存的地方，因此有很多地方都具備有持久層的概念，像資料庫，檔案，或者各類的NoSQL。
雖然cookie,session,cache等不算是持久層，但我建議各位參考這個命名原則來處理key name。廢話不多說我們開始吧！

對資料庫的Table或Column命名其實己經發展很久了，在還沒有關連式資料庫的年代，表和表之間的關係基本上靠猜，想像一下你用100個陣列，然後各自處理不同的東西，還必需要考慮到相互關係。因此在那個年代，每個資料庫都會有一本對應表，說明各表之間的關係。
（現在這種管理方式還會在一些銀行或金融機構出現）
為了便於管理，怎麼對命名就變得格外重要（還記得Hungarian Notation嗎？暴個雷，等一下它會出現），主要就是為了可以快速的找到相對應的關係。
而時至今日，某些管理方式也被帶到了現在，在網路時代也慢慢建立起了一套機制。

Overall

資料庫的命名規則上，各家的做法不太一致，但普遍分成大寫派（如我）和小寫派。
大寫派應該是比較老學究，就是過去我們的訓練就是全大寫，用一些Format tools像ApexSQL也是以大寫為主，因此用大寫理所當然。
但比較新的做法則是以小寫為主，主要是用來突顯語法和參數的不同，這點我也認同。
下面的命名我們會以新的社群標準為主。

Table

資料表會以PascalCase命名，例如InvestorsInfo。
至於要用單數還是複數，我個人是傾向複數，因為Table基本的設計是一個集合。但有人認為應該要用單數，主要是以Record當成主體來看，Table只是裝載這些紀錄的，因此應該要用單數。
無論那種說法都可以被接受，但必需要一致。

Column

資料欄位會以snake_case命名，而且是全小寫，例如user_id。
Column能講的東西就比較多了。首先是命名風格：有些人會把Table name當成前綴詞放在Column前面，例如:

CREATE TABLE Investors(
    invester-id INT NOT NULL,
    invester-name VARCHAR(100) NOT NULL
)

這個回答對，也不對。不對的原因是大部份的情況是沒有必要的，就以每個表它自己就能表現自己的情況，又要再讓每個欄位再自我表述一次自己的用途，就有點太多了。
對的原因是什麼？如果這個欄位他是一個Primary key或Foreign key或可做為FK，時，就應該把他的來源用匈牙利標註的方式，標示在欄位上。所以上面的表會寫成

CREATE TABLE Investors(
    investor-id INT NOT NULL,
    name VARCHAR(100) NOT NULL,
    PRIMARY KEY (investor-id)
)

如此一來在其他的表做為FK時，無論有沒有標記成FK，都會知道他是來自那張表的

CREATE TABLE Product(
    product-id INT NOT NULL,
    name VARCHAR(100) NOT NULL,
    investor-id INT NULL
)

Constraint

現在的DBMS做得愈來愈好，Constaint基本上都都會被管理工具處理掉，開發人員可以在最終的Schema裡看到它。因此Constraint的命名也還算統一，還是採用匈牙利標註，把Constraint name放在最前面，例如PK_Investors。
如果要自己刻的話：例如下Index，也記得要用同樣的方法命名。

Key-Value storage

資料庫說完，我們說一些像Cache或Cookie的命名。一般來說鍵值的名稱，主要還是用kekab-case或snake_case，還是看是習慣後端的寫法還是前端的寫法。無論是那一種，最重要的一點就是要

• 一致性，不要混用各種的命名法
• 可辨識的，在Application或者UI裡至少要能找到設定好的鍵值
• 不容易重覆，這類的Key通常都是全域使用，因此要考慮到不重覆的問題。

以上就是關於儲存媒體的命名規則，比起前面說的東西相對單純多了是吧。